home *** CD-ROM | disk | FTP | other *** search
/ Scene Storm / Scene Storm - Volume 1.iso / coding / asm / games / scrolling_8way / 8wayscroll.readme < prev    next >
Text File  |  1980-01-03  |  16KB  |  482 lines
  1. ;******************************************************************
  2. ;******************************************************************
  3. ;***                                ***
  4. ;***    8-Way-Tile-Scroller                    ***
  5. ;***                                ***
  6. ;***    $VER: 8-Way-Tile-Scroller V1.04 (14.06.93)        ***
  7. ;***                                ***
  8. ;***                                ***
  9. ;***    Coding: Gonzo, Green Rabbits Inc.  (no scene-group)    ***
  10. ;***                                ***
  11. ;***    Contact me via EMail: hollosi@fm11ap01.tu-graz.ac.at    ***
  12. ;***                  (until 1.7.1993)            ***
  13. ;***    or via snail mail:  Arno Hollosi            ***
  14. ;***                Oberndorf 313            ***
  15. ;***                A-6322 Kirchbichl            ***
  16. ;***                AUSTRIA                ***
  17. ;***                                ***
  18. ;******************************************************************
  19. ;******************************************************************
  20.  
  21.  
  22.  
  23. ===========
  24. DISCLAIMER:
  25. ===========
  26.  
  27.   All rights of this archive are owned by me, Arno Hollosi.
  28. You are allowed to use and change the provided source, but only
  29. for your personel purposes.
  30. Any commercial usage without the written permission of the author
  31. is prohibited. Using these routines in any commercial product is
  32. forbidden.
  33.   Only PD and FreeWare authors are allowed to use these routines
  34. in their products, if they mention me in the credits.
  35.  
  36. Copying this archive is allowed, if ALL files are provided and
  37. were not modified.
  38.  
  39. YOU USE THIS SOURCE AT YOUR OWN RISK.
  40. Never will I be liable for any damage caused by using this code;
  41. direct or indirect.
  42.  
  43.  
  44.  
  45. =================
  46. WHAT DO YOU NEED?
  47. =================
  48.  
  49. * You should be able to code in assembler.
  50.   (68000 assembler of course, or what did you think :-)
  51.  
  52. * You should know what the COPPER and the BLITTER are.
  53.   And ofcourse how to use them.
  54.  
  55. * You should own any assembler. No executable provided.
  56.   The source was written with MasterSeka V1.76 by GEORGE II / BUDDHA.
  57.   Don't worry. The code doesn't contain any specific SEKA-features.
  58.   I've tried to assemble it with AsmOne, and it worked, so I don't
  59.   think, that you'll have any problems with other assemblers.
  60.   From V1.04 on it could be assembled with MACRO68 too (did cost me
  61.   about 3 hours of work! Tip: don't use the resident maclibs, or
  62.   many symbols will be redefind->Error. Start Macro68 with:
  63.   '1> macro68 8wayscroll.asm exeobj objfile 8wayscroll' ).
  64.  
  65.  
  66. BTW, my English isn't perfect at all. But I hope, that I didn't make
  67. to many mistakes :-)
  68.  
  69.  
  70. ======================
  71. FILES IN THIS ARCHIVE:
  72. ======================
  73.  
  74.   8wayscroll.asm    the source itself
  75.   scroll_tiles.raw    graphic-data in RAW-Format
  76.   scroll_tiles.pic    graphic-data in IFF/ILBM-format
  77.   8wayscroll.readme    this file
  78.  
  79.  
  80.  
  81.  
  82.  
  83. =================
  84. HOW DOES IT WORK?
  85. =================
  86.  
  87.   As the name says, the graphic is build of tiles. Usually these
  88. tiles are 16pixel * 16pixel big. Have a look at the SCROLL_TILES.PIC,
  89. if you don't understand what I mean.
  90.  
  91. If you have got a big level with, let's say 1600pixel * 1600pixel
  92. you would need 1.6 MByte of CHIPMEM.
  93. If you use the tiles-method, you only have to remember the number
  94. of each tile, thus following: 100tiles * 100tiles * 2byte/tile = 20 KByte.
  95. That's really a difference, isn't it ??
  96.  
  97. An 8-way-tile-scroller is splitted into TWO parts:
  98.  
  99.   * the hardware-scrolling, via BPLCON1 (softscrolling).
  100.     Usually the copper will do the work for us.
  101.  
  102.   * the blitter scrolling. Yep, nothing works without our mighty friend.
  103.     The blitter blits the 16*16 tiles into our buffer.
  104.  
  105. To understand how the scrolling works, I will describe the methods for
  106. vertical and horizontal scrolling seperatly.
  107.  
  108. Let me define some display-values used to describe the scrolling.
  109. (The values are the same as in the source).
  110.  
  111.     visible SCREEN-WIDTH:  288 pixel, or 36 bytes or 18 tiles
  112.     visible SCREEN-HEIGHT: 192 pixel, or 12 tiles
  113.  
  114. BTW, if anywhere in the text I'm talking of THE SCREEN, I mean the
  115. visible area. If I'm talking of THE BUFFER, I mean the complete
  116. memory (visible and hidden area).
  117.  
  118. If anywhere in the text you see something like (->run), then
  119. you should take a look at the source and jump to this label to
  120. see more.
  121.  
  122. Tline means line of tiles. A Tline is 16 pixel-lines high.
  123. Tcolumn means column of tiles. A Tcolumn is 16-pixel wide.
  124.  
  125.  
  126.  
  127.  
  128. ============================================
  129. THE VERTICAL SCROLLING  (Copper-Wrap-Method)
  130. ============================================
  131.  
  132. For the vertical scrolling we need 3 extra-tiles.
  133. This means: buffer_height = screen_height + 3
  134. Therefor our buffer_height is 15 tiles.
  135.  
  136. Imagine that we want to scroll down.
  137. The soft line by line scrolling will be done by the copper.
  138. This means, the copper must set the BPL-pointers at the beginning
  139. of the screen to the proper values (->origcopper,off_plane).
  140.  
  141. During this soft-scrolling we use the blitter to blit a new Tline
  142. at the bottom of the buffer.
  143. The blitting is ofcouse done into a hidden area, so that the user
  144. can't see it. In our case, Tlines 0-11 are visible, Tline 12 gets
  145. visible line by line (soft-scrolling), and we blit into Tline 13.
  146.  
  147. Doing this, we are not able to scroll down forever, because we are
  148. always blitting at the bottom of the screen.
  149.  
  150. There the copper creeps in.
  151. Have a look at this diagram:
  152.  
  153.  
  154.    Phase 0  |  Ph 1 |  Ph 2 |  Ph 3 |  Ph 4 |  Ph 5 |  Ph 6
  155. ------------+-------+-------+-------+-------+-------+---------
  156.      <s             <w     <w     <w     <s
  157.     A|    x    *G    G|    G|    G|    G|
  158.      |     <s         <e     |     |     |
  159.     B|    B|    x    *H    H|    H|    H|
  160.      |     |     <s         <e     |     |
  161.     C|    C|    C|    x    *I    I|    I|
  162.      |     |     |     <s         <e     |
  163.     D|    D|    D|    D|    x    *J    J|
  164.      <e     |     |     |     <s         <e
  165.     *E    E|    E|    E|    E|    x    *K
  166.          <e     |     |     |     <s
  167.     x    *F    F|    F|    F|    F|    x
  168.              <e     <w     <w     <w
  169. ------------+-------+-------+-------+-------+-------+---------
  170.  
  171. Symbols:    <s .. start of visible area
  172.         <e .. end of visible area
  173.         <w .. Copper-wrap; the copper sets the
  174.               BPL-pointers to a new value
  175.  
  176.         A-K .. Tlines
  177.         x  ... content of this Tline doesn't matter.
  178.         * .... blitter is blitting into this Tline
  179.  
  180.         for the diagram following dimensions are given:
  181.         SCREEN-WIDTH: doesn't matter, SCREEN-HEIGHT: 3 tiles
  182.  
  183. Did you catch the point ??
  184. If no, then I'm sorry. Either I'm too silly to explain this, or you
  185. are too ..... :-)
  186.  
  187.  
  188. Advantages:
  189. ===========
  190.  
  191.     * We only need 3 extra Tlines instead of SCREEN-HEIGHT*2.
  192.       This safes a lot of CHIPMEM.
  193.  
  194.     * We only blit ONE Tline per Tline on screen. If you don't
  195.       use the copper-wrap-method it wold be blitting TWO Tlines
  196.       per Tline on screen.
  197.  
  198. Disadvantage:
  199. =============
  200.  
  201.     * The buffer is splitted into 2 parts. This split can be
  202.       (and is the most time) somewhere in the visible area.
  203.  
  204.       Have a look at Phase 4. The copper sets new BPL-pointers
  205.       at the end of Tline 'F', which is approx. the middle of
  206.       the screen.
  207.       If you want to blit a BOB into the buffer, which should
  208.       appear in the middle of the screen, you would have to
  209.       split this BOB into TWO parts. Into an upper half, which
  210.       is blitted somewhere into Tline 'F' and a lower half,
  211.       which gets blitted somewhere into Tline 'G'.
  212.  
  213.     Some people think, that this splitting would cost a lot of
  214.     time, but this isn't true. Try it out yourself.
  215.     (or use sprites :-)
  216.  
  217.  
  218. Have a look at:        -> scroll
  219.             -> copper_scroll, blitter_scroll
  220.             -> blit_y
  221.  
  222. For very clever readers only:
  223. -----------------------------
  224. You surely have recognized, that this method could be done with only
  225. TWO extra-Tlines too. But we use THREE Tlines because:
  226.  * THREE is easier for down AND up scrolling plus
  227.  * THREE is easier for combination with horizontal scrolling.
  228. Why ??
  229. Let me explain:
  230.   Each phase of the diagram is 4 frames (1/50 sec) long.
  231.   4 Frames because of:  MaxSpeed of scrolling down: 4 pixel / frame
  232.             Tline-Height: 16 pixel.
  233.   If we have got a BUFFER-WIDTH of e.g. 20 tiles, we must blit
  234.   20 tiles per phase. Ofcourse we don't blit this 20 tiles at once.
  235.   So we spread our work over 4 frames. Therfor we blit 5 tiles
  236.   per frame (->blt_taby).
  237.   If you don't want to go through hell as I did, then you blit this
  238.   new Tcolumn completly. This means: if the user only goes down 1 pixel
  239.   you blit the whole Tcolumn within 4 frames (->blt_nx, blt_cnty).
  240.   But what happens, if the user changes the direction, just after moving
  241.   down 1 pixel ?? If we had only TWO extra-Tcolumns, we would have to
  242.   blit all 20 tiles in 1 frame !! This would cost too much time.
  243.   Therefor we add a THIRD extra-Tcolumn to avoid such problems.
  244.   Just try to think over it a little bit (tip: use paper&pen :-).
  245.   Why don't we blit accordingly to the Y-position (e.g. user moves two
  246.   pixel -> we blit only 3 (20/16*2) tiles. If he moves back two pixel,
  247.   we only have to restore 3 tiles.) ? Why ??
  248.   Because you'll run into the biggest problems, if you want to combine
  249.   it with horizontal scrolling. Believe me, I've tried it.
  250.  
  251.  
  252.  
  253. =========================
  254. THE HORIZONTAL SCROLLING:
  255. =========================
  256.  
  257. Uff. I've tried to explain this one on comp.sys.amiga.programmers
  258. and discovered that noone seems to understand me. Sniff, sniff.
  259.  
  260. So let's try it again.
  261.  
  262. Your buffer-width must be: 4 extra Tcolumns + SCREEN_WIDTH
  263.  
  264. Four extra-Tcolumns does seem much to you ??
  265. Yes and no. If you compare it to conventionally methods it
  266. is better (other ones need 2*SCREEN_WIDTH).
  267. If you don't combine it with vertical scrolling you can reduce it
  268. to THREE extra Tcolumns. If you only scroll in ONE direction you
  269. only need TWO extra Tcolumns.
  270.  
  271. OK, let's go on.
  272. If we are moving right, then we blit into the right border of the
  273. buffer (invisible). Soft-scrolling will be done with BPLCON1.
  274. After 16 pixels scrolling you'll have to increase the BPL-Pointers
  275. by 2. Never reset the pointers.
  276.  
  277. Swallowed that ??
  278. Some of you are crying, that if we never reset the pointers, then
  279. they are going through the whole memory. For every 16 pixel-scroll
  280. the pointers increase by 2, and therfor if we never reset them, they
  281. will increase until doomsday.
  282.  
  283. Yep. This is exactly right. WE CAN'T SCROLL RIGHT FOREVER.
  284. But it isn't as bad as you think.
  285. We only need 2 bytes more for every 16 pixel-scroll.
  286. Only 2 byte ?? Not more ?
  287. Almost noone realizes why we need only 2 bytes more, and not
  288. 16 pixel*BUFFER_HEIGHT*SCREEN_DEPTH bytes more.
  289.  
  290.  
  291. So look at the following diagram:
  292. ---------------------------------
  293. (the diagram only uses 3 extra-words)
  294.  
  295. Imagine we've got a screen with 2 pixel-lines height and
  296. 3 words width.
  297. The buffer would look like:
  298.  
  299.    xABCDx    <-first line
  300.    xABCDx    <-second line
  301.  
  302. If we have a look into memory, it should look like:
  303.  
  304.    xABCDxxABCDx
  305.     ^     ^
  306.     |    start of second line
  307.    start of first line
  308.  
  309. Diagram:
  310. --------
  311.  
  312. phase    |  memory
  313. --------+------------------------------------------------------
  314.     0    |  xABCD*xABCD*eeee        ;strat phase
  315.     |   ^  !E ^  !E            ;blit column E
  316. --------+------------------------------------------------------
  317.     1    |  xABCDE*ABCDE*eee
  318.         |    ^  !F ^  !F        ;blit column F
  319. --------+------------------------------------------------------
  320.     2   |  xxBCDEF*BCDEF*ee
  321.     |     ^  !G ^  !G        ;blit column G
  322. --------+------------------------------------------------------
  323.     3   |  xxxCDEFG*CDEFG*e
  324.     |      ^  !H ^  !H        ;blit column H
  325. --------+------------------------------------------------------
  326.     4   |  xxxxDEFGH*DEFGH*
  327.     |       ^  !I ^  !I        ;blit column I
  328. --------+------------------------------------------------------
  329.  
  330. Symbols:    ^  ... start of visible area
  331.         !  ... end of visible area
  332.         A-I .. columns of level
  333.         x  ... content of this tile doesn't matter
  334.         e .... extra words at the end of the buffer
  335.                (extra words, NOT extra tiles or extra Tcolumns!!)
  336.  
  337. Dimensions:    height:        2 lines  (but doesn't really matter)
  338.         SCREEN-WIDTH:    3 tiles
  339.         BUFFER-WIDTH:    6 tiles
  340.  
  341. Either you understand it now, or never!
  342. If you have a closer look you should realise:
  343.   * For every 16 pixel we need one more EXTRA-WORD.
  344.   * It doesn't matter how much lines (Tlines) we have got.
  345. Try to understand it. think it over and over again.
  346.  
  347. Did you get the point ??
  348. GREAT!
  349. So if you want to scroll e.g. 20 screens to the right, then you
  350. should allocate 800 bytes more for your buffer.
  351. (800 bytes = 20 screens * 320 pixel/screen).
  352. That isn't much memory, is it ?
  353.  
  354. Advantages:
  355. ===========
  356.  
  357.     * You only have to blit 1 Tcolumn per 16 pixel move,
  358.       instead of 2 TColumns with other methods.
  359.  
  360.     * This method can be easy combined with the vertical scrolling.
  361.  
  362.     * Need less memory than any other method.
  363.  
  364. Disadvantages:
  365. ==============
  366.  
  367.     * You can't scroll right/left forever.
  368.       This doesn't really matter. Even if you scroll
  369.       100 screens (never seen such a game) you only need
  370.       4000 bytes more memory.
  371.  
  372. Have a closer look at:        ->scroll
  373.                 ->copper_scroll
  374.                 ->blitter_scroll
  375.                 ->blit_x
  376.  
  377.  
  378.  
  379. =================
  380. ABOUT THE SOURCE:
  381. =================
  382.  
  383.  
  384. First we allocate memory for our purposes (->run).
  385. Following memory is needed:
  386.     * LEVEL_ADR:    Buffer for level area  (number for each tile)
  387.     * PLNE_ADR:    Buffer for our BUFFER (screen-area visible/invisible)
  388.     * COPPER_ADR:    Buffer for our copperlist
  389.  
  390. After this we load the default view (NULL), which is very important for
  391. AGA-Computers, otherwise the display would be trashed.
  392. Then the system gets killed and we ->init_all.
  393. Then we do our important stuff ->main.
  394. After returning ->delete_all and free memory, wake system from ist
  395. deep sleep.
  396.  
  397. ->Init_Level    initializes the LEVEL-buffer.
  398. ->Init_Copper    builds the copperlist (->origcopper)
  399. ->Print_Lev    prints the LEVEL_DATA the first time, because scrolling
  400.         doesn't fill the visible area at the beginning.
  401.  
  402. ->Get_Joy    reads out the joystick and computes the new
  403.         X & Y values.
  404.  
  405. ->Scroll    just calls copper_scroll and blitter_scroll
  406. ->Copper_Scroll    makes the work for soft-scrolling, which is to set
  407.         BPLCON1, and the BPL-Pointers to proper values.
  408.  
  409. ->Blitter_Scroll
  410.     This is the biggie.
  411.     The first part (until ->blt_done) sets the blt_tab's
  412.     and the blt_cnt's (see vertical scrolling, part: clever readers)
  413.     Look at the macros ->bltxmc,->bltymc. They do the main-work.
  414.  
  415.     After this, blit_x and blit_y are called.
  416.  
  417.     The ->blt_fldy - table is for the blit_x routine.
  418.     blit_x must know, which level-Tline must be blitted into the
  419.     according buffer-Tline.
  420.  
  421.     blit_x, blit_y do the whole work.
  422.     Just have a closer look at them.
  423.  
  424. ->Main        waits for every new frame
  425.         calls ->get_joy and ->scroll
  426.         computes time in rasterlines, used by ->scroll.
  427.         (On an A4000 ->scroll needs max. 10 rasterlines,
  428.          with an A500 I think it shouldn't use more than
  429.          30 rasterlines;  REALLY FAST, DON'T YOU THINK SO? ).
  430.         You can get the used time, after running 8wayscroll.asm
  431.         if you look at <big> with your assembler.
  432.  
  433.  
  434. BTW, the code is not optimized for speed.
  435. There are a lot mulu's and some divu's, that were not avoided
  436. with using tables. And so on...
  437.  
  438.  
  439. On screen you'll see a dark blue moving up/down as you move
  440. up/down with the joystick. At this border the COPPER-WRAP is performed.
  441. The grey-color at the bottom shows you how long it takes the computer
  442. to scroll the screen.
  443. So enjoy !!  (DON'T FORGET THE FIRE-BUTTON)
  444.  
  445.  
  446.  
  447.  
  448. =======
  449. HISTORY
  450. =======
  451.  
  452. V1.04 (14.06.93)
  453.   Corrected bug in 'initcopper'. (MOVE #0,COPJMP1, instead of CLR COPJMP1,
  454.   because CLR does a READ and WRITE cycle on an 68000. Therefor it crashed
  455.   on Amigas with a CPU lower than '020).
  456.   Removed last spaces, that annoyed MACRO68.
  457.   Waitblitter-Macro was changed from 'btst #14' to 'btst #6'.
  458.  
  459. V1.00 (10.06,93)
  460.   First public release
  461.  
  462.  
  463.  
  464.  
  465. =======
  466. THE END
  467. =======
  468.  
  469.  
  470. I hope, that you find this archive usefull, and that I didn't make
  471. to many mistakes.
  472. If you like this source, or if you discover a bug, then don't be
  473. to shy to contact me. I love to get mail.
  474. If you use it in your own production (nothing commercial, remember)
  475. then I would appreciate it very much, if you would send me a copy
  476. of your game.
  477. Look at the addresses in the header.
  478.  
  479.  
  480. CHEERS
  481. Arno
  482.